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^~f0OOl] This application claims the priority of Chinese Patent Application No. 03 103096.3, 
filed January 28, 2003, the disclosure of which is expressly incorporated by reference herein. 

FIELD OF THE INVENTION 

[0002] The present invention relates to a system and method of accessing and 
transmitting data frames, in particular to a system and method of accessing and transmitting 
different data frames in a digital transmission network. 

BACKGROUND OF THE INVENTION 

[0003] Because Ethernet technology is featured with low price and high expansibility, etc., 
it has evolved from a mainstream LAN technology to a primary data service access technology 
and is widely used in Metropolitan Area Network (MAN) by more and more telecom operators. 
Providing Ethernet data services has become a trend for telecom operators. Ethernet data 
services can be classified into two types: Ethernet private line services and Virtual Local Area 
Network (VLAN) services. 

[0004] For convenience, the phrases and abbreviations in the following description have 
the following meanings: MPLS - Multi-protocol Label Switching; GFP - General Frame 
Positioning; VLAN - virtual Local Area Network; VMAN - virtual Metropolitan Area 
Network; RPR - Resilient Packet Ring. 

[0005] Currently, most of the telecom operators* data transmission networks are 
SDH/SONET networks. Therefore, it is a highlight for telecom operators and telecom 
equipment manufacturers to access and transfer Ethernet data frames effectively in a 
SDH/SONET network to meet the increasing demand for Ethernet data services. At present, 
several telecom equipment manufacturers have provided the devices to access and transfer 
Ethernet data frames in a SDH/SONET network, and those devices may be classified into 3 
types according to the implementation approach of functionality: 
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( 1 ) Data mapping/demapping scheme; 

(2) Bridge scheme; 

(3) RPR scheme. 

[0006] Fig. 1 shows a block diagram of a first prior art device according to the data 
mapping/demapping scheme. The device comprises one or more user-network interfaces 
(UNI) 20 (standard Ethernet interfaces), one or more network-network interface (NNI) 30 
(synchronous digital transmission channels), one or more mapping/demapping devices 101, 
102, each of which corresponds to a unique UNI and a unique NNI. The data frames 
entering the device via UNI 20 and data frames output from the device comply with Ethernet 
data standard, and data frames entering the device via NNI 30 and data frame output from the 
device comply with synchronous digital transmission network standard. 

[0007] The mapping/demapping device 10 maps Ethernet data frames entering the device 
via UNI 20 to become synchronous digital data frames, and outputs the mapped data frames via 
NNI 30. The mapping/demapping device 10 demaps the synchronous digital data entering the 
device via NNI to Ethernet data frames, and outputs the data frames via the UNI. However, the 
functionality of the device is simple, thus it can only provide Ethernet private line services. 

[0008] Fig. 2A shows a block diagram of another prior art device utilizing a bridge scheme. 
The device comprises one or more UNIs 20 (standard Ethernet interfaces), each of which 
corresponds to a unique bridge port. The device further comprises one or more NNIs 30 
(synchronous digital transmission channels). The device further comprises a bridge device 400 
(described in detail in IEEE802.1D and IEEE802.1Q), wherein the bridge device 400 
comprises a plurality of bridge ports, each of which corresponds to a unique UNI or a unique 
mapping/demapping device. Each mapping/demapping device corresponds to a unique bridge 
port and a unique NNI. The data frames entering the device via UNI 20 and the data frames 
output from the device comply with the Ethernet data standard, and data frames entering the 
device from NNI 30 and data frame output from the device comply with the standard of 
synchronous digital transmission network. 



[0009] Data frames entering the device via UNI 20 enter the bridge device 400 via the 
bridge port corresponding to the UNI, the bridge device 400 calculates the bridge output port 
according to the address information in the data frames and sends the data frames to the 
corresponding mapping/demapping device 102, which maps the data frames and then outputs 
them to the NNI, via the output port, and vice versa. 

[0010] In the bridge scheme, usually the operator is allowed to map some or all UNIs to 
mapping/demapping devices in a one-to-one way through configuration. In this case, the 
device employs both of above technical schemes, so it is called an enhanced bridge scheme. 
The functional model of an enhanced bridge device is shown in Fig. 2B. 

[0011] Disadvantages of the second prior art device are: 

(1) It is unable to provide integral VLAN service. If a plurality of users are 
attached to the device via UNIs and there are conflicts among address spaces of Ethernet data 
frames of those users, the device is unable to isolate the conflicts effectively. Thus it is 
unable to provide services correctly to those users. 

(2) A common bridge (non-enhanced bridge) is unable to provide Ethernet 
private line service. 

(3) A UNI can only support one service type (Ethernet private line service or 
VLAN service), which limits the access capability of the device. In some cases, though the 
processing capacity of the device is still sufficient, new devices have to be added to improve 
access capacity because the UNIs have been used up. 

(4) A NNI can only support one service type (Ethernet private line service or 
VLAN service), which leads to low convergence capability of the device. In some cases, in a 
star topology network, though the processing capacity of the device is still sufficient, new 
devices have to be added to improve convergence capacity because the NMs have been used 
up. For operators, it means not only new investment but also bandwidth waste. 

[0012] Fig. 3 shows a block diagram of a third prior art device utilizing RPR scheme. The 



device comprises one or more UNIs (standard Ethernet UNIs), two NNIs (synchronous digital 
transmission channels), and a RPR device 600 (described in IEEE802.17), two 
mapping/demapping devices, and a data processing device 500 which may be a data 
converging/diverging device or a bridge device. 

[0013] The data frames entering the device via the UNI 20 are processed as follows: 

[0014] Step 1 : the data processing device 500 processes the data frames (the data frames 
are converged if the data processing device is a data converging/diverging device; the data 
frames are switched if the data processing device is a bridge device); 

[0015] Step 2: the data processing device 500 transfers the processed data frames to the 
RPR device 600; 

[0016] Step 3: the RPR device 600 sends the data frames to the corresponding 
mapping/demapping device according to the address information in the data frames; and 

[0017] Step 4: the mapping/demapping device performs a mapping operation for the data 
frames and sends them to the outside of the device via the corresponding N NL 

[0018] The data frames entering the device via the NNI are processed as follows: 

[0019] Step 1: the mapping/demapping device performs a demapping operation for the 
data frames and transfers the demapped data frames to the RPR device 600; 

[0020] Step 2: the RPR device 600 processes the data frames and then sends them to the 
data processing device; 

[0021] Step 3: the data processing device 500 processes the data frames (the data frames 
are diverged if the data processing device is a data converging/diverging device; the data 
frames are switched if the data processing device is a bridge device); and 

[0022] Step 4: the data processing device 500 finds the corresponding UNI according to the 
address information in the data frames and then outputs the data frames via the UNI. 



[0023] Disadvantages of this scheme are: 

(1) It is unable to provide Ethernet private line service and VLAN service at 
the same time. If the data processing device is a bridge device, it doesn't support Ethernet 
private line service. If the data processing device is a data converging/diverging device, it 
doesn't support VLAN service. 

(2) It can only be used in a ring topology network. 
SUMMARY OF THE INVENTION 

[0024] An object of the present invention is to provide a data processing and dispatching 
device in an SDH/SONET network and the method of accessing and transmitting Ethernet data 
frames thereof, in order to provide individualized service and improve the service capability of 
the device. 

[0025] According to one aspect of the present invention, it is provided a method of 
processing data through a system for accessing and transmitting different data frames in a 
digital transmission network. This system includes at least a UNI, which is used to couple 
with the user's network; at least an NNI, which is used to couple with the digital transmission 
network to transfer data; at least one mapping/demapping device; a virtual interface device, 
which couples with at least one UNI and couples with at least one NNI via the 
mapping/demapping device; a control device, which couples with the virtual interface device 
to control it to access and transmit the data frames. The method comprises the steps of the 
virtual interface device classifying the data frames, and the virtual interface device outputting 
the data frames to the corresponding device interfaces. 

[0026] Preferably, the control device includes a data processing and dispatching device, 
which couples with the virtual interface device; at least one virtual private device and/or at least 
one virtual bridge device and/or at least one RPR device, which couples with the data 
processing and dispatching device. The method also comprises the step of the virtual bridge 
device switching the data frames. 



[0027] Optionally, the control device comprises: a data processing and dispatching 
device, which couples with the virtual interface device; at least one virtual private device 
and/or at least one virtual bridge device and/or at least one RPR device, which couples with the 
data processing and dispatching device. The method also comprises the step of the virtual 
private device processing the data frames. 

[0028] Preferably, the step of the virtual private device processing the data frames 
comprises the following step: relaying and/or converging and/or diverging the data frames. 

[0029] Optionally, the step of the virtual private device processing the data frames also 
comprises the following step: the RPR device processing the data frames. 

[0030] Preferably, the step of the RPR device processing the data frames comprises the 
following step: terminating sending and/or relaying and/or beginning to send the data frames. 

[0031] Optionally, the step of the RPR device processing the data frames also comprises 
the following step: the RPR device processing the data frames. 

[0032] Preferably, the step of the RPR device processing the data frames comprises the 
following step: terminating sending and/or relaying and/or beginning to send the data frames. 

[0033] The system and method according to the present invention have the following 
advantages: 

(1) With the system and method of the present invention, operators can adjust 
the processing flow in the device flexibly according to the network topology, users' 
requirements, and bandwidth resource, etc., to improve the processing ability and efficiency 
of bandwidth. 

(2) With the system and method of the present invention, fast and 
individualized service can be provided for users. Operators can provide new services for 
users through establishing new processing flow combination when the system is not upgraded 
and new devices are added. 



[0034] Other objects, advantages and novel features of the present invention will become 
apparent from the following detailed description of the invention when considered in 
conjunction with the accompanying drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0035] Fig. 1 shows a block diagram of a data mapping/demapping scheme according to a 
first prior art device; 

[0036] Fig. 2A shows a block diagram of a bridge scheme according to a second prior art 
device; 

[0037] Fig. 2B shows a block diagram of an enhanced bridge scheme according to the 
second prior art device; 

[0038] Fig. 3 shows a block diagram of a RPR scheme according to a third prior art device; 

[0039] Fig. 4 shows a schematic diagram of a preferred embodiment of a system accessing 
and transmitting Ethernet data frames in an SDH/SONET network according to the present 
invention; 

[0040] Fig. 4 (F) shows a data processing flowchart of a preferred embodiment of the 
system accessing and transmitting Ethernet data frames in an SDH/SONET network; 

[0041] Fig. 4A shows a schematic block diagram of a virtual interface device in a preferred 
embodiment of the system accessing and transmitting Ethernet data frames in an SDH/SONET 
network according to the present invention; 

[0042] Fig. 4 A (Fl) shows a flowchart of a virtual interface device processing the data 
entering from the interface of a processing device in a preferred embodiment of the system for 
accessing and transmitting Ethernet data frames in an SDH/SONET network according to the 
present invention; 

[0043] Fig. 4A (F2) shows a flowchart of a virtual interface device processing the data 



entering from the inter-device interface in a preferred embodiment of the system for accessing 
and transmitting Ethernet data frames in an SDH/SONET network according to the present 
invention; 

[0044] Fig. 5 shows a schematic block diagram of a virtual private device in a preferred 
embodiment of the system accessing and transmitting Ethernet data frames in an SDH/SONET 
network according to the present invention; 

[0045] Fig. 5 (F) shows a flowchart of a virtual private device processing the data entering 
from the inter-device interface in a preferred embodiment of the system for accessing and 
transmitting Ethernet data frames in an SDH/SONET network according to the present 
invention; 

[0046] Fig. 6 shows a schematic block diagram of a virtual bridge device in a preferred 
embodiment of the system for accessing and transmitting Ethernet data frames in an 
SDH/SONET network according to the present invention; 

[0047] Fig. 6 (F 1 ) shows a flowchart of a virtual bridge device processing the data entering 
from the inter-device interface in a preferred embodiment of the system accessing and 
transmitting Ethernet data frames in an SDH/SONET network according to the present 
invention; 

[0048] Fig. 6 (F2) shows a flowchart of a broadcasting sub-flow of the virtual bridge 
device processing the data entering from the inter-device interface in a preferred embodiment 
of the system for accessing and transmitting Ethernet data frames in an SDH/SONET network 
according to the present invention; 

[0049] Fig. 6 (F3) shows a flowchart of a multicasting sub-flow of the virtual bridge device 
processing the data entering from the inter-device interface in a preferred embodiment of the 
system for accessing and transmitting Ethernet data frames in an SDH/SONET network 
according to the present invention; 

[0050] Fig. 7 shows a schematic block diagram of a data processing and dispatching device 



in a preferred embodiment of the system for accessing and transmitting Ethernet data frames in 
an SDH/SONET network according to the present invention; 

[0051] Fig. 7 (F) shows a flowchart of a data processing and dispatching device processing 
the entered data in a preferred embodiment of the system accessing and transmitting Ethernet 
data frames in an SDH/SONET network according to the present invention; 

Detailed description of Embodiments 

[0052] To make the system and method of the present invention better understood, the 
basic function of a device is described first. Usually, all devices have the following three 
functions: 

(1) Input function, i.e., receive external information; 

(2) Processing function, i.e., process the external information; 

(3) Output function, i.e., output the processed information. 

[0053] A device for accessing and transmitting Ethernet data frames in a SDH/SONET 
network includes: 

(1) Input function: receive external information via the UNIs and the NNIs; 

(2) Processing function: for a device for accessing and transmitting Ethernet 
data frames in an SDH/SONET network, different processing ability as well as service ability 
and service efficiency depend on different technical schemes; and 

(3) Output function: output the processed information via the UNI and the 

NNI. 

[0054] In addition, the phrase "standard Ethernet interface" used in the present application 
means the following: 

[0055] IEEE802.3 defines the LAN interface in detail; Such an interface is regarded as a 



standard Ethernet interface in the present invention. 

[0056] The present invention will be described hereunder with reference to the drawings. 
For concision, components and units described in prior art will not be described in detail 
hereunder. And components and units described above will not be described in detail 
hereunder. 

[0057] Fig. 4 shows a system that accesses and transmits different data frames in a digital 
transmission network. The system comprises a plurality of UNIs designed to couple with the 
users' networks, a plurality of NNIs designed to couple with the digital transmission network to 
transmit data, a plurality of mapping/demapping devices 10, a virtual interface device 80 
coupled with the UNIs and also coupled with the NNIs via the mapping/demapping devices 10, 
a data processing and dispatching device 90 coupled with the virtual interface device 80, a 
virtual private device 120 and a plurality of virtual bridge devices 100 and a RPR device 110 
coupled with data processing and dispatching device. Although a virtual private device 120, a 
plurality of virtual bridge devices 100 and a RPR device 110 are described in the present 
application, it should be noted that a combination of any one or two of them can implement the 
present invention. The input to system comprises: (1) data frames entering the system via the 
UNIs and (2) data frames entering the system via the NNIs. The data frames output from 
system comprises: (1) data frames from the UNIs and (2) data frames from the NNIs. 

[0058] Fig. 4 (F) shows the processing steps for data frames entering the system via the 
UNIs. 

[0059] First, in step 1, the virtual interface device performs a matching action to the data 
frames according to classifying rules; 

[0060] In step 2, the virtual interface device modifies the data frames according to 
classifying rules, i.e., inserts a data type number in the data frames; 

[0061] In step 3, the virtual interface device transfers the modified data frames to the data 
processing and dispatching device; 
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[0062] In step 4, the data processing and dispatching device finds a corresponding 
processing device according to the data type number in the data frames; 

[0063] In step 5, the data processing and dispatching device transfers the data frames to the 
corresponding processing device, it i s determined whether the data frames are r . ent to the 
proc e ssing d e vic e or th e virtual interfac e devic e. If the corresponding device is a the data 
fram e s ar e s e nt to th e virtual interface device, go to step 8; if th e data frames ar e sent to the 
processing d e vic e , go to st e p 6 . 

[0064] In step 6, the corresponding processing device processes the data frames, modifies 
the data type number at the end of the processing, and then transfers the modified data frames 
to the data processing and dispatching device; 

[0065] In step 7, go to step 4; 

[0066] In step 8, the virtual interface device finds the corresponding device interface 
according to the data type number in the data frames; 

[0067] In step 9, the virtual interface device modifies the data frames, i.e., it deletes the 
data type number from the data frames; 

[0068] In step 10, the virtual interface device outputs the modified data frames via the 
device interface (if the device interface is an NNI, a mapping operation should be performed 
through the mapping/demapping device before output). 

[0069] The processing steps for data frames entering the device via the NNI are as follows: 

[0070] In step 1, the mapping/demapping device performs a demapping operation to the 
data frames; 

[0071] In step 2, the remaining processing steps are identical to those for data frames 
entering the system via the UNIs. 

[0072] The main components of the system for accessing and transmitting different data 
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frames in a digital transmission network is now described with reference to the drawings. 

[0073] Fig. 4A shows a schematic block diagram of a virtual interface device in a preferred 
embodiment of the system accessing and transmitting Ethernet data frames in a SDH/SONET 
network according to the present invention. A virtual interface device 80 is used to enhance 
access ability. Via the virtual interface device 80, a device interface (UNI 20 or NNI 30) may be 
expanded to a plurality of virtual interfaces, each of which supports specific users and services. 
For data frames entering the system via the device interfaces (UNI 20 and NNI 30), the virtual 
interface processing unit 800 of the virtual interface device will classify them according to 
different services required by the users and choose corresponding processing for them. 
Different processing corresponds to different rules in the rule database 850. The control 
interface unit controls the virtual interface processing unit 800 to classify the data frames 
according to the orders from the control interface and searches for corresponding rules stored 
in the rule database 850 to process the data. Data frames output from the device are transferred 
to a corresponding device interface after classified in the virtual interface device. Because the 
virtual interface device stores N rules, the mapping relationship between the device interface 
and those rules is 1:N. The rules in the virtual interface device may be set up or deleted 
dynamically. Therefore, it is easy to modify the rules to enhance the adaptability of the system 
according to the users 1 requirements and the updating of the system. The device also comprises 
a software loader (not shown) to load different software. 

[0074] As the processing center, the virtual interface processing unit 800 is responsible for 
processing data frames. The processing steps and processing logic in the virtual interface 
processing unit are firmware and can't be modified during operation of the system. The rule 
database is the control center and is responsible for providing relevant processing and control 
parameters when the virtual interface processing unit processes the data frames. Different 
parameters lead to corresponding processing behaviors. During operation of the system, the 
rules in the rule database may be updated. The control interface unit provides an external 
control interface. Via the control interface, the control system of the device may monitor the 
virtual interface processing unit and performs adding, deleting, editing, and querying 
operations to the rules in the rule database. The rule database may store a plurality of rules, 
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each of which contains five parts: a device interface number, data frame type number, data 
frame address offset, data frame type value, and data frame comparison mask. 

[0075] Wherein the virtual interface device is connected to the UNIs or the NNIs via the 
device interfaces: The mapping relationship between the UNIs (or NNIs) and the device 
interfaces is 1:1. The virtual interface device is connected to the data processing and 
dispatching device via the inter-device interface. The virtual interface device is connected to 
the control system of the device via the control interface. 

[0076] Fig. 4A (Fl) shows the steps of the virtual interface processing unit processing data 
frames entering the virtual interface device via the device interface: 

[0077] Step 1: searching for the first rule in the rule database corresponding to the device 
interface with the index of the device interface number; 

[0078] Step 2: examining the searching result; if it is blank, discarding the data frames and 
going to step 10; 

[0079] Step 3: reading information at an address offset of the data frame according to the 
data frame address offset in the rule; 

[0080] Step 4: performing an "AND" operation between the read information and data 
frame comparison mask in the rule; 

[0081] Step 5: comparing the result of step 4 with the data frame type value in the rule; if 
they are equal, going to step 8; 

[0082] Step 6: searching for the next rule corresponding to the device interface in the rule 
database; 

[0083] Step 7: going to step 2; 

[0084] Step 8: modifying the data frame, i.e., inserting data type number information in the 
rule in the head position of the data frames; 
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[0085] Step 9: transferring the data frames to the data frame processing and dispatching 
device via the inter-device interface; 

[0086] Step 10: ending the process. 

[0087] Fig. 4A (F2) shows the steps of the virtual interface processing unit processing data 
frames entering the virtual interface device via the inter-device interface. The processing steps 
are as follows: 

[0088] Step 1: extracting the data frame type information from a head position of the data 
frames; 

[0089] Step 2: searching in the rule database with the index of the data frame type number; 

[0090] Step 3: determining the searching result; if it is blank, discarding the data frames 
and going to step 6; 

[0091] Step 4: modifying the data frames, i.e., deleting the data frame type number 
information from a head position of the data frames; 

[0092] Step 5: sending the data frames to a corresponding device interface according to the 
device interface number in the rule; 

[0093] Step 6: ending the process. 

[0093.1] The system accessing and transmitting Ethernet data frames in an SDH/SONET 
network comprises a plurality of UNIs designed to couple with the users 1 networks, a plurality 
of NNIs designed to couple with the digital transmission network to transmit data, a plurality of 
mapping/demapping devices 10, a virtual interface device 80 coupled with the UNIs and also 
coupled with the NNIs via the mapping/demapping devices 10, a data processing and 
dispatching device 90 coupled with the virtual interface device 80, a virtual private device 120 
and a plurality of virtual bridge devices 100 and a RPR device 110 coupled with the data 
processing and dispatching device. Although a virtual private device 120, a plurality of virtual 
bridge devices 100 and a RPR device 1 10 are described in the present invention, it should be 
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noted that a combination of any one or two of them can implement the present invention. 

[0094] Fig. 5 shows a schematic block diagram of a virtual private device in a preferred 
embodiment of the system accessing and transmitting Ethernet data frames in an SDH/SONET 
network according to the present invention. In the virtual private device, a virtual private 
processing unit 8001 is coupled with the inter-device interface to process the data from the 
inter-device interface. The virtual private processing unit 8001 is also coupled to the rule 
database and the control interface unit. The control interface unit exchanges data with the 
outside world via the control interface. 

[0095] The present invention enhances the converging ability of the system by utilizing the 
virtual private device. The virtual private device stores converging rules, diverging rules, and 
relay rules (the relay rules are optional and unnecessary in some simple virtual private devices). 
The mapping relationship between the data types and the rules is 1:1. The rules in the virtual 
private device can be set up and deleted dynamically. Data frames of different users can be 
isolated, transmitted and shared by adding a label before sending, changing the label during 
transmission and removing the label at the destination address. A virtual private device 
comprises a virtual private processing unit and a rule database in it. 

[0096] The virtual private processing unit has two major functions: 

(a) Detecting control messages and transferring the control messages to the 
control system of the device via the control interface unit. 

(b) Performing a convergence, divergence, or relay operation for data frames 
except for the control messages. 

[0097] The virtual private processing unit is the processing center of the device; the 
following items are stored in the virtual private processing unit as firmware: 

(a) Format of control messages; 

(b) Processing steps and logic for data frames; 
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(c) Format of rules in the rule database; 

[0098] As the control center, the rule database controls the processing action of the virtual 
private processing unit. The rules in the rule database may be updated dynamically. The rule 
database may store a plurality of rules, each of which comprises the following information: an 
input data frame type number, rule type (convergence/divergence/relay), label number, and 
output data frame type number. 

[0099] Wherein the virtual private device is connected to the data processing and 
dispatching device via the inter-device interface; the virtual private device is connected to the 
control system of the device via the control interface. 

[0100] There are different technical schemes for implementing the virtual private device. 
However, the data frame processing steps and logic in the virtual private processing unit is 
identical under these schemes. The main differences between these schemes are: 

(a) Format of rules in the rule database, for example, the length and position of 
label in the rule are different; 

(b) Format of control messages processed in the virtual private processing unit. 

[0101] In view of expandability and compatibility, it is recommended to implement the 
virtual private device with MPLS, GFP, VMAN, or Nested VLAN technique. The device 
manufacturers may also employ self-defined label formats (or self-defined data frame packets) 
to implement the virtual private device. The system may support a plurality of virtual private 
devices implemented with different technical schemes. 

[0102] Fig. 5 (F) shows a flowchart of the virtual private device; for data frames entering 
the device via the inter-device interface, the processing steps of the virtual private processing 
unit are as follows: 

[0103] Step 1 : determining whether the data frames are control messages; if yes, going to 
step 3; 
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[0104] Step 2: transferring the data frames to an external control system via the control 
interface unit, and then going to step 12; 

[0105] Step 3: extracting the input data type number information from the head position 
of the data frames; 

[0106] Step 4: searching in the rule database with the index of the input data type number 
information; 

[0107] Step 5: determining the searching result; if it is blank, discarding the data frames 
and going to step 12; 

[0108] Step 6: determining the rule type; if it is a convergence rule, going to step 7; if it is 
a divergence rule, going to step 8; if it is a relay rule, going to step 9; 

[0109] Step 7: modifying the data frames, i.e., inserting a label number defined in the rule 
at a special position in the data frames, and then going to step 10; 

[0110] Step 8: modifying the data frame, i.e., removing the label number at the special 
position in the data frames, and then going to step 10; 

[0111] Step 9: modifying the data frames, i.e., replacing the label number at the special 
position in the data frames with a label number defined in the rule; 

[0112] Step 10: modifying the data frames, i.e., replacing the data type number at the 
head position of the data frames with the output data type number defined in the rule; 

[0113] Step 1 1 : transferring the data frames to the data frame processing and dispatching 
device via the inter-device interface; 

[0114] Step 12: ending the process. 

[0115] Fig. 6 shows a schematic block diagram of a virtual bridge device in a preferred 
embodiment of the system accessing and transmitting Ethernet data frames in an 
SDH/SONET network according to the present invention. The present invention overcomes 
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the issue of limited Ethernet data frame address space through a virtual bridge device. A 
virtual bridge device may provide a plurality of virtual bridges. Each virtual bridge possesses 
all features and properties of the bridge device. However, it is different from the bridge 
device in that the virtual bridge may be set up and deleted dynamically. During the operation 
of the system, the operator may set up or delete a plurality of virtual bridges dynamically 
because each virtual bridge has an independent address space, the operator may provide 
VLAN services to users with different virtual bridges if conflicts exist among address spaces. 

[0116] The operator may configure a virtual bridge just like a physical bridge. The virtual 
bridge further expands the features of physical bridge to support the VMAN-based switching 
operation. A virtual bridge device comprises a virtual bridge processing unit 802, a 
multicasting database 856, a control interface unit, a forwarding database 852, and a virtual 
bridge database 854. 

[0117] The virtual bridge processing unit has three major functions: 

(a) Detecting control messages and transferring the control messages to the 
control system of the device via the control interface unit. 

(b) Learning addresses, and storing the knowledge acquired into the forwarding 

database; 

(c) Performing switching for data frames except for control messages and 
modifying data type information in the data frames. 

[0118] The virtual bridge processing unit is the processing center of the device, and there 
are five items embedded in it: 

(a) Format of control messages; 

(b) Processing steps and logic for data frames; 

(c) Format of forwarding items in the forwarding database; 
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(d) Format of multicasting items in the multicasting database; 

(e) Format of items in the virtual bridge database 



[0119] The virtual bridge database, multicasting database, and forwarding database 
control the processing behaviors of the virtual bridge processing unit, and the items in them 
may be updated during operation of the system. The data formats of items in the multicasting 
database and forwarding database are identical, and each item contains the following 
information: 

(a) Virtual bridge number; 

(b) Input port of virtual bridge; 

(c) Destination address input; 

(d) VLAN serial number input; 

(e) VMAN serial number input; 

(f) Output port of virtual bridge; 

[0120] In the multicasting database, the database code is the combination of all fields; in 
the forwarding database, the database code is the combination of all fields except for the 
output port of the virtual bridge. 

[0121] Each item in the virtual bridge database contains the following information: 

(a) Type number input; 

(b) Virtual bridge number; 

(c) Port number; 

(d) Type number output; 

[0122] Via the control interface, an external control system may implement the following 
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functions: 

(a) Performing adding, deleting, editing, and querying operations to items in the 

database; 

(b) Monitoring the working state of the virtual bridge processing unit. 

[0123] The virtual bridge device is connected to the data processing and dispatching 
device via the inter-device interface. The virtual bridge device is connected to the control 
system of the device via the control interface. 

[0124] Fig. 6 (Fl) shows a flowchart of the virtual bridge device processing the data 
entering the inter-device interface in a preferred embodiment of the system for accessing and 
transmitting Ethernet data frames in an SDH/SONET network according to the present 
invention. For data frames entering the device via the inter-device interface, the virtual bridge 
processing unit performs the following processing steps: 

[0125] Step 1 : determining whether the data frames are control messages; if yes, going to 
step 3; 

[0126] Step 2: transferring the data frames to an external control system via the control 
interface unit, and then going to step 17; 

[0127] Step 3: extracting the input data type number, destination address, source address, 
VLAN number, and VMAN number (optional) from a fixed position in the data frames; 

[0128] Step 4: searching in the virtual bridge database with the index of the data type 
number extracted; 

[0129] Step 5: determining the searching result; if it is blank, discarding the data frames 
and going to step 17; 

[0130] Step 6: obtaining the virtual bridge number and port number information from the 
search result; 
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[0131] Step 7: learning the source address, and then updating the forwarding database 
according to the learnt result; 

[0132] Step 8: determining whether the destination address is a multicasting address; if 
yes, executing a multicasting sub-flow, and then going to step 17; 

[0133] Step 9: determining whether the destination address is a broadcast address, if yes, 
executing a broadcasting sub-flow, and then going to step 17; 

[0134] Step 10: searching in the forwarding database with the index of the virtual bridge 
number, input port, and destination address, VLAN number, and VMAN number (optional); 

[0135] Step 11: examining the search result; if it is blank, executing a broadcasting 
sub-flow, and then going to step 17; 

[0136] Step 12: extracting the output port number from the searching result; 

[0137] Step 13: searching in the virtual bridge database with the index of the virtual 
bridge number and the output port number; 

[0138] Step 14: examining the search result; if it is blank, discarding the data frames and 
going to step 17; 

[0139] Step 15: extracting the output type number from the searching result and 
modifying the data frame, i.e., replacing the type number in the data frames with the output 
data type number; 

[0140] Step 16: outputting the modified data frames via the inter-device interface; 
[0141] Step 17: ending the process. 

[0142] Fig. 6 (F2) shows a flowchart of broadcasting sub-flow of the virtual bridge 
device processing data from inter-device interface in a preferred embodiment of the system 
for accessing and transmitting Ethernet data frames in an SDH/SONET network according to 
the present invention. The processing steps of the broadcasting sub-flow are as follows: 
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[0143] Step 1: searching for the first item corresponding to the virtual bridge in the 
virtual bridge database with the index of the virtual bridge number; 

[0144] Step 2: examining the retrieval result; if it is blank, discarding the data frames and 
going to step 7; 

[0145] Step 3: comparing the input type number in the retrieval result with the type 
number in the data frames; if they are equal, going to step 6; 

[0146] Step 4: copying the data frames, extracting the output type number information 
from the retrieval result, and then modifying the copied data frames, i.e., replacing the type 
number in the copied data frames with the output type number; 

[0147] Step 5: outputting the modified copied data frames via the inter-device interface; 

[0148] Step 6: searching for the next item corresponding to the virtual bridge in the 
virtual bridge database with the index of the virtual bridge number, then going to step 2; 

[0149] Step 7: the sub-flow ending. 

[0150] Fig. 6 (F3) shows the flowchart of multicasting sub-flow of virtual bridge device 
processing data from an inter-device interface in a preferred embodiment of the system of 
accessing and transmitting Ethernet data frames in a SDH/SONET network according to the 
present invention. The processing steps of the multicasting sub-flow are as follows: 

[0151] Step 1 : With the index of a virtual bridge number, input port number, destination 
address, VLAN number, and VMAN number (optional), searching for the first item 
corresponding to these key words in the multicasting database; 

[0152] Step 2: determining the retrieval result; if it is blank, discarding the data frames 
and going to step 9; 

[0153] Step 3: comparing the output port number in the retrieval result to the extracted 
input port number (the input port number corresponding to the type number of the data 
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frames in the virtual bridge database); if they are equal, going to step 8; 

[0154] Step 4: searching in the virtual bridge database with the index of a virtual bridge 
number and an output port number; 

[0155] Step 5: examining the retrieval result; if it is blank, discarding the data frames and 
going to step 8; 

[0156] Step 6: copying the data frames, extracting the output type number information 
from the retrieval result, and then modifying the copied data frames, i.e., replacing the type 
number in the copied data frames with the output type number; 

[0157] Step 7: outputting the modified copied data frames via the inter-device interface; 

[0158] Step 8: With the index of a virtual bridge number, input port number, destination 
address, VLAN number, and VMAN number (optional), searching for the next item 
corresponding to these key words in the multicasting database, then going to step 2; 

[0159] Step 9: the sub-flow ending. 

[0159.1] The system comprises a plurality of UNIs designed to couple with the users' 
networks, a plurality of NNIs designed to couple with the digital transmission network to 
transmit data, a plurality of mapping/demapping devices 10, a virtual interface device 80 
coupled with the UNIs and also coupled with the NNIs via the mapping/demapping devices 
10, a data processing and dispatching device 90 coupled with the virtual interface device 80, 
a virtual private device 120 and a plurality of virtual bridge devices 100 and a RPR device 
110 coupled with the data processing and dispatching device. Although a virtual private 
device 120, a plurality of virtual bridge devices 100 and a RPR device 110 are described in 
the present invention, it should be noted that a combination of any one or two of them can 
implement the present invention. 

[0160] Fig. 7 shows a schematic block diagram of a data processing and dispatching 
device in a preferred embodiment of the system for accessing and transmitting Ethernet data 
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frames in an SDH/SONET network according to the present invention. The data processing 
and dispatching device is coupled with a plurality of inter-device interfaces to process the 
data from the inter-device interfaces. The data processing and dispatching device is also 
coupled with the processing flow database and the control interface unit. The control 
interface unit exchanges data with the outside world via the control interface. 

[0161] The present invention utilizes the data processing and dispatching device to 
implement individualized services to improve equipment serviceability. The data processing 
device stores a plurality of processing flows. The mapping relationship between the 
processing flows and the data frame types is 1:1. The data processing and dispatching device 
finds the corresponding processing flow according to the data frame type, and informs other 
devices to process the data frames according to the processing flow. The processing flows in 
the data frame processing device may be set up, edited, or deleted dynamically. During the 
operation of the system, the operator may quickly provide individualized services to 
maximize the efficacy of the system through adding, editing, and deleting the processing 
flows in the data processing device. 

[0162] The data processing and dispatching device is the processing center of the system, 
and the processing flows are embedded in it as firmware. There are a plurality of inter-device 
interfaces in the data processing and dispatching device, each of which maps to a unique 
external device. The mapping relationship between the inter-device interfaces and the 
external devices are fixed. 

[0163] The processing flow database is the control center of the system, and the items in 
the database may be updated dynamically. Each processing flow in the processing flow 
database contains the following information: 

(a) Data frame type number; 

(b) Inter-device interface number 

[0164] The data processing and dispatching device is connected to other devices via the 
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inter-device interfaces, each of which maps to a virtual bridge device, a virtual private device, 
a RPR device, or a virtual interface device. The data processing and dispatching device is 
connected to the control system of the device via the control interface. 

[0165] Fig. 7 (F) shows a flowchart of the data processing and dispatching device 
processing the data entering the device in a preferred embodiment of the system for accessing 
and transmitting Ethernet data frames in an SDH/SONET network according to the present 
invention. The processing steps are as follows: 

[0166] Step 1 : extracting the type number from the data frames; 

[0167] Step 2: searching in the processing flow database with the index of the extracted 
type number; 

[0168] Step 3: examining the searching result; if it is blank, discarding the data frames 
and going to step 6; 

[0169] Step 4: extracting the inter-device interface number from the searching result; 

[0170] Step 5: outputting the data frames via the inter-device interface corresponding to 
the inter-device interface number; 

[0171] Step 6: ending the process. 

[0172] Application of the system: 

[0173] The operator may utilize the system shown in Fig. 4 to provide users with 
Ethernet services, which correspond to various combinations of processing flows. The 
operator may define and choose required processing flow combinations flexibly according to 
network topology, the users' service demands and the bandwidth resource. Processing flow 
combinations common used are as follows: 

[0174] Processing flow combination 1 : 

(1) The virtual interface device classifies the data frames; 
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(2) The virtual interface device outputs the data frames to corresponding 
device interfaces. 

[0175] Processing flow combination 2: 

(1) The virtual interface device classifies the data frames; 

(2) The virtual bridge device switches the data frames; 

(3) The virtual interface device outputs the data frames to corresponding 
device interfaces. 

[0176] Processing flow combination 3: 

(1) The virtual interface device classifies the data frames; 

(2) The virtual private device processes the data frames (relay, converge, or 

diverge); 

(3) The virtual interface device outputs the data frames to corresponding 
device interfaces. 

[0177] Processing flow combination 4: 

(1) The virtual interface device classifies the data frames; 

(2) The RPR device processes the data frames (terminates, relays, or starts 
data frame transmission); 

(3) The virtual interface device outputs the data frames to corresponding 
device interfaces. 

[0178] Processing flow combination 5: 

(1) The virtual interface device classifies the data frames; 

(2) The virtual bridge device switches the data frames; 
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(3) The virtual private device converges the data frames; 

(4) The virtual interface device outputs the data frames to corresponding 
device interfaces. 

[0179] Processing flow combination 6: 

(1) The virtual interface device classifies the data frames; 

(2) The virtual private device diverges the data frames; 

(3) The virtual bridge device switches the data frames; 

(4) The virtual interface device outputs the data frames to corresponding 
device interfaces. 

[0180] Processing flow combination 7: 

(1) The virtual interface device classifies the data frames; 

(2) The virtual private device diverges the data frames; 

(3) The virtual bridge device switches the data frames; 

(4) The virtual private device converges the data frames; 

(5) The virtual interface device outputs the data frames to corresponding 
device interfaces. 

[0181] Processing flow combination 8: 

(1) The virtual interface device classifies the data frames; 

(2) The RPR device terminates sending the data frames; 

(3) The virtual bridge device switches the data frames; 

(4) The virtual interface device outputs the data frames to corresponding 
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device interfaces. 

[0182] Processing flow combination 9: 

(1) The virtual interface device classifies the data frames; 

(2) The virtual bridge device switches the data frames; 

(3) The RPR device begins to send the data frames; 

(4) The virtual interface device outputs the data frames to corresponding 
device interfaces. 

[0183] Processing flow combination 10: 

(1) The virtual interface device classifies the data frames; 

(2) The RPR device terminates sending the data frames; 

(3) The virtual bridge device switches the data frames; 

(4) The RPR device begins to send the data frames; 

(5) The virtual interface device outputs the data frames to corresponding 
device interfaces. 

[0184] Processing flow combination 1 1 : 

(1) The virtual interface device classifies the data frames; 

(2) The virtual private device converges the data frames; 

(3) The RPR device begins to send the data frames; 

(4) The virtual interface device outputs the data frames to corresponding 
device interfaces. 

[0185] Processing flow combination 12: 
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(1) The virtual interface device classifies the data frames; 

(2) The RPR device terminates sending the data frames; 

(3) The virtual private device diverges the data frames; 

(4) The virtual interface device outputs the data frames to corresponding 
device interfaces. 

[0186] Processing flow combination 13: 

(1) The virtual interface device classifies the data frames; 

(2) The RPR device terminates sending the data frames; 

(3) The virtual private device relays the data frames; 

(4) The RPR device begins to send the data frames; 

(5) The virtual interface device outputs the data frames to corresponding 
device interfaces. 

[0187] Processing flow combination 14: 

(1) The virtual interface device classifies the data frames; 

(2) The RPR device terminates sending the data frames; 

(3) The virtual private device diverges the data frames; 

(4) The virtual bridge device switches the data frames; 

(5) The virtual interface device outputs the data frames to corresponding 
device interfaces. 

[0188] Processing flow combination 15: 

(1) The virtual interface device classifies the data frames; 
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(2) The virtual bridge device switches the data frames; 

(3) The virtual private device converges the data frames; 

(4) The RPR device begins to send the data frames; 

(5) The virtual interface device outputs the data frames to corresponding 
device interfaces. 

[0189] Processing flow combination 16: 

(1) The virtual interface device classifies the data frames; 

(2) The RPR device terminates sending the data frames; 

(3) The virtual private device diverges the data frames; 

(4) The virtual bridge device switches the data frames; 

(5) The virtual private device converges the data frames; 

(6) The RPR device begins to send the data frames; 

(7) The virtual interface device outputs the data frames to corresponding 
device interfaces. 

[0190] Processing flow combination 1 7: 

(1) The virtual interface device classifies the data frames; 

(2) The virtual private device diverges the data frames; 

(3) The RPR device terminates sending the data frames; 

(4) The virtual interface device outputs the data frames to corresponding 
device interfaces. 

[0191] Processing flow combination 18: 
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(1) The virtual interface device classifies the data frames; 

(2) The RPR device begins to send the data frames; 

(3) The virtual private device converges the data frames; 

(4) The virtual interface device outputs the data frames to corresponding 
device interfaces. 

[0192] Processing flow combination 19: 

(1) The virtual interface device classifies the data frames; 

(2) The virtual private device diverges the data frames; 

(3) The RPR device relays the data frames; 

(4) The virtual private device converges the data frames; 

(5) The virtual interface device outputs the data frames to corresponding 
device interfaces. 

[0193] Processing flow combination 20: 

(1) The virtual interface device classifies the data frames; 

(2) The virtual private device diverges the data frames; 

(3) The RPR device terminates sending the data frames; 

(4) The virtual bridge device switches the data frames; 

(5) The virtual interface device outputs the data frames to corresponding 
device interfaces. 

[0194] Processing flow combination 2 1 : 

(1) The virtual interface device classifies the data frames; 
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(2) The virtual bridge device switches the data frames; 

(3) The RPR device begins to send the data frames; 

(4) The virtual private device converges the data frames; 

(5) The virtual interface device outputs the data frames to corresponding 
device interfaces. 

[0195] Processing flow combination 22: 

(1) The virtual interface device classifies the data frames; 

(2) The virtual private device diverges the data frames; 

(3) The RPR device terminates sending the data frames; 

(4) The virtual bridge device switches the data frames; 

(5) The RPR device begins to send the data frames; 

(6) The virtual private device converges the data frames; 

(7) The virtual interface device outputs the data frames to corresponding 
device interfaces. 

[0196] When implementing functions of the system, the device manufacturers may 
partially or completely employ the above method. For devices with simple functions, partial 
components can be omitted and the processing is relatively simple. The device manufacturers 
may even treat the processing as firmware through fixing connections among the devices to 
omit the data processing and dispatching device. For instance, for a device that only provides 
Ethernet private service, it may only comprises the following devices: 

(1) One or more UNIs; 

(2) One or more NNIs and mapping/demapping devices; 
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(3) A virtual interface device; 

(4) A virtual private device. 

[0197] The device supports the following processing flow combinations: 

( 1 ) Processing flow combination 1 ; 

(2) Processing flow combination 3. 

[0198] With the system and method of the present invention, integral VLAN services can 
be provided for users. The system and method in the present invention overcome the 
restriction on Ethernet data frame address space at UNIs. When a plurality of Ethernet data 
frames is sent to such a network device, there is no restriction on address space of Ethernet 
data frames. 

[0199] With the system and method of the present invention, a device interface (UNI or 
NNI) supports both VLAN service and Ethernet private service, and a plurality of Ethernet 
data frames from many users can be accessed and converged at a single device interface, thus 
the accessing and converging capability of the device is enhanced greatly. 

[0200] With the system and method of the present invention, the operator may maximize 
processing capacity of its equipments and utilization ratio of bandwidth resource through 
flexible adjustment to internal processing flows according to network topology, the users' 
service demands, and bandwidth resource. 

[0201] With the system and method of the present invention, individualized services can 
be quickly provided for users. The operator may provide new services to users through 
creating new flow combinations, without upgrading or adding new equipment. 

[0202] According to the present invention, data frames entering the device via device 
interfaces are processed after being classified; different data types correspond to different 
processing flows, which are implemented by virtual interface devices. 
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[0203] Existing technical schemes and devices have to be implemented on a presumption: 
data frames from a device interface belong to the same type, and different types of data 
frames enter the device via different device interfaces. Therefore, in the prior art technical 
scheme and system, data frames entering the device via the same device interface are 
processed through the same processing flow, thus the mapping relationship between 
processing flows and device interfaces is 1: n. As a result, when there are many data types, 
though the processing capacity of the device is still sufficient enough, some services can't be 
supported due to lack of free device interfaces. 

[0204] Whereas with the system and method of the present invention, data frames from a 
device interface may contain various types, and processing flows for different types of data 
frames are different; the mapping relationship between processing flows and device interfaces 
is m: n. 

[0205] In addition, the present invention supports free combination of processing flows; 
the combination of a data processing and dispatching device and its processing flows is an 
important part of the present invention. 

[0206] Existing technical schemes and devices have no data processing and dispatching 
device and only support several fixed processing flows. As a result, they lack flexibility and 
resiliency. However, the requirements of operators for equipment are changing. 

[0207] A system lacking flexibility and resiliency is unable to adapt to a changing 
environment. With the present invention, the operator can update the processing flows 
dynamically, and users can choose appropriate flow combinations or create new flow 
combinations as required. There are 22 or more processing flow combinations available. 

[0208] In existing technical schemes and devices, the amount of bridge devices is certain; 
so conflicts among data frame address spaces of different users can be avoided only through 
restricting the data frame address spaces of users. Whereas the virtual bridge devices in the 
present invention support dynamical expansion (i.e., add new virtual bridges), and the address 
space of each virtual bridge is independent; different virtual bridges correspond to different 
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users; hence the present invention has no restriction to data frame address spaces of users. 

[0209] In addition, data frames of different users can be isolated, transmitted and shared 
by adding a label before sending, changing the label during transmission and removing the 
label at destination address, thus the virtual private device of the present invention is 
achieved. 

[0210] Though the present invention is described with reference to above embodiments, it 
is understood that any skilled in this field can easily make any change and modification 
without escaping the spirit of the present invention. So any change and modification should 
be in the scope of the present invention. 

[0211] The foregoing disclosure has been set forth merely to illustrate the invention and 
is not intended to be limiting. Since modifications of the disclosed embodiments 
incorporating the spirit and substance of the invention may occur to persons skilled in the art, 
the invention should be construed to include everything within the scope of the appended 
claims and equivalents thereof. 
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